An interrupt is a control transfer mechanism that causes a processor to stop execution of a current program and start execution of an interrupt handler. When the interrupt handler has completed handling of the interrupt, the processor resumes execution of the interrupted program. A distinction is often made between external interrupts and exceptions. An "external interrupt" is an interrupt that is caused by physical events that occur outside of the program currently being executed by the processor. An external interrupt is asynchronous with the program currently being executed. An "exception", in contrast, is caused by physical events that occur inside of the processor (i.e., internal events), and an exception is generally synchronous with the program that is currently being executed. Exceptions include "faults" and "traps". For purposes of simplicity, both an external interrupt and an exception will be referred to hereinafter as an "interrupt". The term "interrupt" is also used herein to encompass a software-generated interrupt.
It is often necessary for application programs to gain access to system interrupts. To enable the applications to gain access to the system interrupts, many operating systems provide "hooks". A hook is a mechanism that allows an application program to gain access to system interrupts.
The WINDOWS, version 3.0, graphical user interface sold by Microsoft Corporation of Redmond, Wash., is built upon an MS-DOS foundation. WINDOWS, version 3.0, also includes a DOS protected mode interface (DPMI). DPMI allows DOS applications to run on a processor in protected mode, such as found in 80286-based systems and 80386-based systems. When a WINDOWS application program seeks to gain access to system interrupts, it must rely on services provided by MS-DOS or DPMI to hook the system interrupts. One difficulty in hooking system interrupts using MS-DOS or DPMI services is that applications are only allowed to unhook themselves from the system interrupt chain (i.e., the sequential chain of applications requesting access to the interrupts) in the reverse order in which the applications were hooked into the system interrupt chain.
FIGS. 1a, 1b and 1c provide an illustration of how applications are hooked into the system interrupt chain using MS-DOS services. In FIGS. 1a-1c, it is supposed that the interrupt is generated in an 80386-based system. In fact, in the remainder of the discussion that follows, the focus will be on an 80386-based system. It should be realized that the present invention is equally applicable to 80286-based systems. FIG. 1a illustrates an instance wherein an application 12 does not yet have a hook into the interrupt chain. In FIG. 1a, an interrupt is directed to a location 14 within the MS-DOS system memory space 10 that holds a pointer. The pointer points to an interrupt handler 16 in the system space 10 for handling the interrupt.
In FIG. 1b, the application 12 has a hook into the interrupt chain so that the pointer in location 14 points to an interrupt handler 18 in the application 12. The hook allows the interrupt handler 18 of the application 12 to receive and service the interrupt. As shown in FIG. 1c, application 12 holds a pointer 20 to the old interrupt handler 16. The interrupt chain, thus, includes a hook that passes the interrupt to the application 12 and a hook that passes the interrupt to the old interrupt handler 16 in the system space 10.
An interrupt chain that is created in a fashion like that shown in FIGS. 1a, 1b and 1c may only be unhooked in reverse order. The interrupt chain cannot be readily traversed because the pointer 20 to the old interrupt handler 16 is held at a location that is not readily discernible outside the application.
A further problem found in environments, such as WINDOWS, version 3.0, is that the interrupts received from MS-DOS and the interrupts received from DPMI may not be handled by the same code because the parameters for the respective interrupt handlers differ.
An additional problem that is particular to conventional systems in which interrupts are hooked through DPMI services relates to the stacks that are employed within the data processing system. A stack is a last-in-first-out (LIFO) structure that is used by a processor to implement nested sub-routine calls, nested sub-routine returns and interrupts. In order to understand how the stack is used in implementing interrupts, it is helpful to consider an example of an interrupt in a 80386-based system.
Suppose that an application program is currently being executed by a processor. The application program is allocated a stack within the local memory that is provided for the program. In 80386-based systems, the stack is part of conventional memory, and the "current" stack is the one at SS:SP, where SS is the current value in the SS register and SP is the current value in the SP register. Further suppose that the application program is interrupted. The system then takes steps to transfer control to an interrupt handler routine. However, in order to be able to return to the application program after the interrupt has been handled, certain information is pushed onto the stack of the application program. The value of the FLAGS register at the time of the interrupt is pushed onto the stack of the application program. The FLAGS register holds status information for the processor. Values for the CS register and IP register are also pushed onto the stack. The values held in the CS register and the IP register depend upon the type of interrupt that has arisen. In addition, certain interrupts push an error code onto the application program stack.
When the interrupt is hooked by DPMI services, the stack is switched to a DPMI stack. The DPMI stack lacks the local variables and other state information that were on the application program stack. As such, the interrupt handler does not have ready access to these missing items. The missing items may be helpful in determining what caused the interrupt. A similar problem arises when the system is running in enhanced mode of WINDOWS, version 3.0. When the system is running in WINDOWS, version 3.0, enhanced mode, the interrupt automatically causes the system to switch to a system stack that, likewise, does not include the local variables and other information that was held on the application program stack.